Every day there is more and more data and there are more and more people and processes that want to access that data. Managing the ever increasing amount of data for the ever increasing number of accessing entities continues to produce new challenges. One approach to managing data so that it can be shared by multiple entities includes distributing data between multiple computers and storage devices, creating multiple access controllers that manage access to the data, and then allowing different entities access to different access controllers. This data management approach may facilitate actions including file creation, file storing, data storing, file sharing, and data sharing. The data management approach may provide enterprise data management features including online tiering, online archiving, de-duplication, replication, distributed data moving, partial file retrieval, shared file system support, and other features.
The number of computers, processes, and storage devices that can participate in a system that manages data can be truly staggering. For example, thousands of clients may interact with hundreds of servers and tens of thousands of storage devices. Millions of items may be stored and made available. Clients that access data, servers that control storing and providing data, and devices that store data may be connected in different ways including a storage area network (SAN), a local area network (LAN), and other connections. In one example, LAN-based access may be provided using clustered gateway systems. To work well together, these devices may need to communicate their location, state, and other information to various controllers or to each other.
In a managed data environment, the data to be shared and accessed does not exist in a vacuum. There is data about the data that is also stored to facilitate locating, using, protecting, replicating, and de-duplicating data. This data about the data may be referred to as metadata. Specialized devices and/or processes that may be referred to as metadata controllers may be tasked with managing metadata. To access data, clients may communicate with one or more metadata controllers. Being able to effectively access stored data is facilitated by communicating with a metadata controller. Communicating with a metadata controller requires a client to know things like where a metadata controller is located, paths for reaching that metadata controller, the state of a metadata controller (e.g., up, down, slow, secure, compromised, etc.), and other things. Conventionally, a name server protocol may have kept clients aware of the location and state of various metadata controllers.
Communicating with a metadata controller may have been complicated by the fact that metadata controller processes could move around a data management environment. For example, a metadata controller process could move from a heavily burdened server to a less burdened server, or a metadata controller could move from a server whose network connections are over-whelmed to a server whose network connections are not so busy. There are many reasons why a metadata controller could migrate between servers and/or server processes. Regardless of the reason why a metadata controller moved, a client may wish to keep track of where a metadata controller is located and may wish to keep track of the state of the metadata controller. A client may wish to have visibility into the state of a metadata controller to facilitate actions like understanding when, if ever, a data request will be satisfied, whether a data request is likely to complete in a relevant time period, whether a metadata controller can satisfy a data request, whether a metadata controller is still alive, and other data access issues.
As already mentioned, conventionally, a name server protocol may have kept clients aware of the location and state of various metadata controllers. However, as data management environments have grown, conventional communication protocols employed by conventional name servers may have produced undesirable side effects as the volume of communications between clients and metadata controllers reached burdensome and/or fatal proportions. For example, an unacceptably or undesirably large amount of the communication bandwidth in a data management environment may have been consumed by metadata controller messages that sought to keep clients informed about the location and state of a metadata controller.